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(54) Protected software 

(57) The functionality of "protected shareware" is 
controlled by digitally signed messaging protocol. Pro- 
tective code within the shareware controls the tunction- 
ality of the shareware in response to authorization mes- 
sages which are supplied directly or indirectly by the 
shareware supplier. These messages are digitally 
signed in whole or part by or on behalf of the shareware 
supplier using the supplier's secret signing key The 
shareware, in turn, includes the public checking key for 
this digital signature of the supplier, thereby enabling the 
protective code to authenticate any such authorization 
message before acting in reliance upon it. The share- 
ware includes an integrity self-checking routine which is 
run at appropriate times to ensure that shareware, in- 
cluding its protective code, is in an anticipated state. 
Typically this is equivalent to a finding that the code has 
not been altered, but it is conceivable that the code 
might be dynamically altered in some authorized (i.e., 
"anticipated") way. 




'User A paid his SO cent 
bill thb month, 5/98. Billing 
computer 8347234234 can 
keep running his software.* 
Signed: The billing agency. 



'User A's total software usage 
this month, 5/98. 50 cents for 
use of Fred's Fine Software* 
Signed: the billing computer 
whh public key 6347234234 
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Billing info: *Poy 50 cents to Fred's Fine Sof tware," 
Nonce: 92849606983629590 
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12 "The billing info is: pay 50 cents 
to Fred's Fine Software. 
The nonce is: 92849606983629590. 
You are authorized to execute.* 
Signed: the billing computer 
with public key 8347234234 



Certificate: 'Public key 8347234234 
is valid until 12/31/98.' 
Signed: The billing agency. 
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Description 

[0001] This invention relates to countermeasures for 
combating computer software "piracy" and, more partic- 
ularly, to techniques for protecting executable computer 5 
programs (including informally distributed programs) 
against unauthorized use. 

[0002] The distribution of computer software funda- 
mentally involves two parties: the software author or the 
author's successor in interest (i.e., the "supplier") and a 
prospective end user. In a standard commercial trans- 
action, the end user usually is motivated to acquire a 
legitimate right to use identified software in a particular 
computing environment on a satisfactory schedule, 
while the supplier generally is interested in receiving an 
acceptable return on the transaction. Various formalized 
distribution strategies, such as the use of retail outlets, 
direct sales, mail order distribution, etc., have been de- 
veloped to resolve the competing interests of these par- 
ties, but many of the more popular distribution tech- 
niques tend to burden the distribution process with costs 
which add little, if any, value to the underlying software. 
For example, software suppliers frequently incur pack- 
aging and handling costs which add no substantive val- 
ue to the software, but which add to the cost of delivering 
the software to the end users. 

[0003] Furthermore, conventional commercial soft- 
ware distribution strategies too often fail to provide ad- 
equate protection against unauthorized use of the soft- 
ware. A few suppliers still "copy protect" their program 
offerings, but this practice has fallen into general disfa- 
vor because it restricts the ability of legitimate users to 
configure and backup their computing systems in ac- 
cordance with their individual needs and preferences. 
Thus, some software suppliers have elected to forego 
the use of built in anti-piracy mechanisms all together, 
while others have adopted inconvenient countermeas- 
ures that are somewhat less objectionable to the user 
community. For example, some programs are designed 
to run only if the host computer has a program specific 
"dongle" on a designated port, other programs are de- 
signed to run only if the user correctly responds to a que- 
ry which tends to verify the legitimacy of the user (such 
as a query requesting information from a specific page 
of the program documentation), and still other programs 
are designed to run only after they have been "person- 
alized" with, say, a user name and/or address. 
[0004] Computer "shareware" is distributed more in- 
formally and with less overhead cost than standard com- 
mercial software. The user-to-user distribution process 
that shareware tends to promote is at least arguably bet- 
ter aligned with the fundamental character of executable 
computer programs than the direct marketing/retail dis- 
tribution model that now dominates the distribution of 
commercial software because an executable program 
essentially is intangible information which is represent- 
ed by a pattern of binary "1's" and "0's". Others have 
recognized the potential of shareware as a vehicle for 



distributing commercial software, but it has been difficult 
to capitalize in the commercial market on the efficiency 
and effectivity of this distribution model because there 
has been no easily implemented, built-in protection 
mechanism for enforcing the software suppliers' com- 
pensation expectations. 

[0005] Mori et al., "Superdistribution: The Concept 
and Architecture", The Transactions of the IEICE, Vol. 
E73, No. 7, July 1 990, pp. 1 1 33-11 46 addresses this en- 
forcement issue, but it suggests encrypting the soft- 
ware. Unfortunately, however, when an ordinary key en- 
cryption technique is employed for encrypting software 
which is subject to unrestricted distribution for use by 
any user, then the key for decrypting the software must 
necessarily also be available to any user. Mori et al., 
propose the use of stringent physical security measures 
for reducing the risk of divulging key contents to the us- 
ers, but system security is questionable at best if a single 
common key must be available to all host computers on 
which the encrypted shareware might run. If, on the oth- 
er hand, multiple keys are used, then multiple versions 
of the software must be created and distributed which 
is often a severe inconvenience. Also see, Mori et al., 
"Superdistribution: An Electronic Infrastructure for the 
Economy of the Future", Trans, of Information Proc. 
Soc. of Japan, Vol. 38, No. 7, July 1 997, pp 1 465 - 1 472. 
[0006] Consequently, there still is a need for a cost 
effective response to the challenge of affording compu- 
ter software suppliers adequate protection against un- 
authorized use of their executable computer program of- 
ferings when unrestricted distribution and installation of 
these programs is permitted (i.e., when a shareware dis- 
tribution model is employed). For commercial applica- 
tions, it would be desirable to have a system solution for 
automatically carrying out at least the basic elements of 
a commercial transaction, including communicating the 
supplier's asking price for program usage rights to the 
prospective user, registering the user's payment or 
promise to pay, and denying or revoking the user's us- 
age rights if payment is not timely received. Further- 
more, it would be advantageous for this solution to per- 
form these functions even if the system resources which 
enforce the supplier's interests only have intermittent 
access to the host computer on which the user decides 
to run the shareware program. 

[0007] In accordance with the present invention, a 
method for protecting an executable computer program 
from unauthorized use independently of any methodol- 
ogy for distributing said program to prospective users 
comprises the. steps of: inhibiting at least some function- 
al feature of said program from running on a compatible 
stored program computer until said computer receives 
a message that is digitally signed by an authorized party 
using a secret signing key; providing said program ac- 
cess to a public checking key for said secret signing key 
in said program; running an integrity self-check over 
said program to confirm that said program is in an an- 
ticipated state; communicating a message that is digit- 
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ally signed with said secret signing key to said computer 
for tentatively approving the running of said functional 
feature of said program on said computer; applying said 
public checking key to said digitally signed message for 
authenticating it; and enabling said functional feature to 
run on said selected computer in response to the au- 
thentication of said message, provided that it has been 
confirmed that said program is in said anticipated state. 
[0008] Thus, for example, the functionality of "protect- 
ed shareware" is controlled by digitally signed messag- 
ing protocol. Protective code within the shareware con- 
trols the functionality of the shareware in response to 
authorization messages which are supplied directly or 
indirectly by the shareware supplier. These messages 
are digitally signed in whole or part by or on behalf of 
the shareware supplier using the supplier's secret sign- 
ing key. The shareware, in turn, includes the public 
checking key for this digital signature of the supplier, 
thereby enabling the protective code to authenticate any 
such authorization message before acting in reliance 
upon it. The shareware includes an integrity self-check- 
ing routine which is run at appropriate times to ensure 
that shareware, including its protective code, is in an an- 
ticipated state. Typically this is equivalent to a finding 
that the code has not been altered, but it is conceivable 
that the code might be dynamically altered in some au- 
thorized (i.e., "anticipated") way. 
[0009] Additional objects and advantages of this in- 
vention will become apparent when the following de- 
tailed description is read in conjunction with the attached 
drawings, in which: 

Figure 1 diagrammatically illustrates a process for 
applying the present invention to commercial share- 
ware; 

Figure 2 schematically illustrates a hardware imple- 
mentation of the process shown in Figure 1; and, 
Figures 3 to 5, are simplified logical flow diagrams 
for a protected program, a billing agency and a bill- 
ing computer, respectively, which communicate (as 
indicated by the dashed lines) to carry out a version 
of this invention. 

[0010] Turning now to the drawings, and at this point 
especially to Figure 1, a somewhat elaborated embod- 
iment of the invention is shown to illustrate a suitable 
implementation for simple commercial applications. 
However, at a more fundamental level, it will be ob- 
served that an executable computer program 11 that is 
protected in whole or part in accordance with this inven- 
tion includes embedded protective code which interacts 
with the existing state of the runtime environment for the 
program 11 in accordance with predetermined rules. 
These rules, in turn, are selected to cause the protective 
code to modify the functionality of the program 1 1 in pre- 
determined ways as a function of predefined, recogniz- 
able changes in the state of the runtime environment. 
[001 1] For example, in a relatively straightforward ap- 
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plication of this invention, the protective code might sim- 
ply limit the functionality of the protected program 11 un- 
less and until an authorization message is received, di- 
rectly or indirectly, from a source 13 which is trusted by 

5 the program supplier, such as a supplier controlled com- 
puter. In practice, the communication channel between 
the protected program 1 1 and the trusted source 1 3 may 
not be secure, so the source 13 suitably authenticates 
each of the authorization messages that it issues on be- 

10 half of the program supplier by digitally signing each of 
them with the program supplier's secret signing key. 
Then, to enable the protective code for the program 11 
to verify the authenticity of any apparent authorization 
message that it receives prior to acting in reliance on it, 

is the protected program 11 includes the public checking 
key for the supplier's secret signing key This public 
checking key may be authenticated by the integrity self- 
check. Alternatively, the program 11 may include a hash 
value for this public checking key and have provision for 

20 authenticating the public checking key from this hash 
value. Moreover, still other known authentication meth- 
ods can be used to authenticate the supplier's public 
checking key. 

[001 2] As will be appreciated, the interaction between 

2S the protective code and the runtime environment for the 
protected program 1 1 need not be a simple binary func- 
tion. Instead, the protective code may give the user ac- 
cess to incrementally differing functional performance 
capabilities of the program 11 in response to different 

30 prespecified states of the runtime environment. Further- 
more, the protective code may be programmed to mod- 
ify its response to any one or more of the recognizable 
states of the runtime environment for the program 11 as 
a function of time and/or as a function of any other ap- 

35 propriately monitored variable. For instance, the protec- 
tive code may be programmed to engage the source 1 3 
in a re-authorization process under predetermined con- 
ditions, such as after the protected program 1 1 has been 
used pursuant to a prior authorization for a fixed period 

40 of real time or run time, or upon the arrival of a date 
certain. 

[0013] In keeping with one of the important features 
of this invention, provision is made for reducing the risk 
of the protective code for the program 11 from being by- 

45 passed or overridden. To this end, the protected pro- 
gram 11 advantageously includes an integrity self- 
checking mechanism which invokes predetermined 
countermeasures (e.g., functionally inhibiting the pro- 
tected program 11 and/or launching warning messages 

so to the program supplier or the supplier's agent, such as 
the trusted source 1 3) if it is found that the integrity of 
the program 11 has been compromised. For example, 
the protected program 11 might include a check sum 
routine for computing a sum over the existing version of 

55 the program code at more or less randomly selected 
times and for then comparing each of these computed 
sums against a precomputed integrity reference so that 
appropriate countermeasures can be taken if there is 
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any discrepancy. While this integrity self-checking may 
not provide fail-safe protection for the protective code, 
the self-checking may be sufficiently sophisticated to 
create a meaningful economic barrier against code al- 
tering attacks. For instance, a series of integrity checks 
can be implemented so that every integrity check, ex- 
cept for the last, is monitored by the next integrity check 
in this series. As will be understood, the code for imple- 
menting such an integrity check can be embedded vir- 
tually anywhere within the protected program 11 as a 
distributed or non-distributed routine. 
[0014] The issuance of a properly authenticated au- 
thorization message by the source 13 may be precon- 
ditioned upon the source 13 being directly or indirectly 
notified that there is at least apparent compliance with 
certain prerequisites. Accordingly this invention can be 
employed for protecting executable computer programs 
against unauthorized use whenever the suppliers of 
such programs are prepared to grant program usage 
rights subject to apparent compliance with predeter- 
mined, monitorable conditions. It may not be practical 
or even feasible to provide absolute compliance guar- 
antees, but compliance assurances of sufficient reliabil- 
ity to reasonably protect the program suppliers' interests 
usually can be provided. Therefore, this invention may 
result in greater reliance on the shareware software dis- 
tribution model, including by program suppliers who are 
specifically interested in being paid for the use of their 
programs. 

[0015] In keeping with the commercial flavor of the il- 
lustrated embodiment, the source 13 of the digitally 
signed authorization messages is shown as being a 
central billing agency which represents the interests of 
the supplier of the protected program 11, possibly to- 
gether with the interests of the suppliers of other simi- 
larly protected programs (not shown). Prospective users 
of the protected program 1 1 could be required to contact 
this billing agency 1 3 for authorization prior to being giv- 
en access to the protected features of the program 11 . 
However, such a pre-approval process might be found 
to be too restrictive and could even prove to be coun- 
terproductive because a substantial portion of the pro- 
spective users may not have convenient, more or less 
real time access to the billing agency 13. Thus, an au- 
thorization process which requires only occasional in- 
teraction with the central billing agency 13 is favored. 
For example, a process that involves regularly sched- 
uled contact, such as monthly contact, with the billing 
agency 1 3 may strike a reasonable balance between the 
avoidance of user inconvenience and the protection of 
the program supplier's interests. 
[001 6] To give the program supplier some flexibility in 
establishing and revising the terms and conditions that 
govern an authorized use of a protected program, such 
as the program 11, provision is made for storing a se- 
lected set of accounting routines in each prospective us- 
er's local computing environment (i.e., in the user's host 
computer 1 2 or in a peripheral unit, as at 15 in Figure 2, 



that is interfaced with the computer 12 as more fully de- 
scribed hereinbelow). The protected program 1 1 , in turn, 
includes calls to preselected ones of these routines for 
communicating the supplier's terms and conditions for 

5 authorized use of the program 11 to the prospective us- 
er, such as via the standard display interface of the com- 
puter 12, and for recording the user's acceptance and/ 
or rejection of this offer in a suitable memory. For exam- 
ple, the supplier might specify that the protected pro- 

10 gram can be used for 30 days at no charge and establish 
a $50 annual or paid-up license fee for any use beyond 
this initial free trial period. As will be understood, a clock, 
such as shown at 16 in Figure 2, is a useful tool to have 
for tracking the time periods specified by such offers, 

'5 but the supplier's expectations and the user's accept- 
ance of such an offer otherwise are self-defined. Thus, 
additional calls to the accounting routines are included 
in the protected program 11 for causing data pertaining 
to any usage of the protected program 1 1 to be recorded 

20 in tamper resistant, non-volatile memory, such as the 
non-volatile random access memory (RAM) 1 7 in Figure 
2. This usage data, in turn, is communicated to the cen- 
tral billing agency 1 3 on a selected schedule via a suit- 
able communication link. For example, a modem 18 

25 may be employed for communicating the usage data to 
the billing agency via the public switched telephone net- 
work. 

[0017] Alternatively, the accounting and billing func- 
tions could be performed internally to the user's compu- 
te ter 12. This could be done by supplementing an ordinary 
personal computer or workstation with a secure kernel 
that operates with protected memory which is inacces- 
sible to the user except through the approved account- 
ing routines. It is believed that programmers who are 
35 generally familiar with the concepts underlying such 
software could readily implement a secure process for 
handling the limited task of billing information in soft- 
ware. This, of course, would reduce the cost and com- 
plexity of any special purpose hardware that might be 
40 required to carry out this invention. 

[0018] As illustrated, however, the computer 12 (e.g., 
a personal computer, a computer workstation, or any 
other type of stored program controlled computer) of 
each prospective user of the protected program 11 has 
45 a serial or parallel data port which is interfaced with a 
special purpose billing computer 1 5. As shown in further 
detail in Figure 2, this billing computer 15 has a proces- 
• sor 21 for managing all memory transactions involving 
the non-volatile RAM 17, a read-only memory (ROM) 
50 22, and some additional volatile or non-volatile RAM 23. 
The non-volatile RAM 1 7 stores the usage data, and the 
ROM 22 stores the accounting routines. Thus, to pre- 
vent unauthorized manipulation of this information, and 
of any "scratch pad" data that may be written into the 
55 RAM 23, the billing computer 15 advantageously is de- 
signed to be "tamper resistant", using any of the known 
techniques for providing such tamper resistance. The 
clock 16 then is desirably included in the billing compu- 
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ter 15 to take advantage of this tamper resistance. The 
modem 18, on the other hand, may be internal of or ex- 
ternal to the billing computer 1 5. If an internal modem is 
employed, it suitably is plugged into a standard tele- 
phone interface (not shown) and configured to allow tel- 
ephone signals to pass to and from other equipment (al- 
so not shown) when it is in an idle state. In practice, it 
may be most cost effective to use embedded processor 
technology to implement the billing computer 15 as a 
"single chip" computer. 

[001 9] Conceivably, an attack against the billing com- 
puter 15 could result in the divulgation of its secret sign- 
ing key. Even then, however, the protected program 11 
could protect itself against a fraudulent manipulation of 
the date as known to the billing computer 15 by checking 
the expiration date on the authentication certificates that 
it receives from the billing agency 1 3 via the billing com- 
puter 15 against a date inferred from its operating envi- 
ronment, such as by checking the dates on the most re- 
cent data files. The use of these authenticating certifi- 
cates is describe in some additional detail hereinbelow. 
[0020] Returning to Figure 1, communications be- 
tween the billing agency 1 3 and the billing computer 1 5 
generally are carried by unsecure communication links. 
Thus, to ensure the integrity of the information they ex- 
change, the billing agency 13 and the billing computer 
15 typically not only digitally sign the messages they 
transmit to each other with their respective secret sign- 
ing keys, but also have a priori knowledge of each others 
public checking keys so that they can validate those 
messages upon receipt. 

[0021] If desired, a software program (not shown) can 
be provided to enable the user to interrogate the billing 
computer 15 for data relating to the current or accumu- 
lated usage charges that the user has incurred, the pay- 
ment status of the user's account, etc. This program may 
be a stand alone program or a utility that is included in 
the protected program 11. The user is merely given 
tamper resistant, read only access to the billing data, so 
the billing interrogation program need not be secure. 
[0022] The authenticity of the message traffic be- 
tween the billing agency 1 3 and the billing computer 1 5 
is assured by the above-described digital signature pro- 
tocol. However, there still is a risk of a successful "spoof- 
ing" attack against the protected program 11, unless 
provision is made for authenticating any message which 
purports to authorize the user's computer 1 2 to execute 
any of the protected code of the program 11 . For exam- 
ple, a fraudulent authorization message might be com- 
municated to the computer 1 2 by an imitator (not shown) 
of the billing computer 1 5 whose behavior would be un- 
predictable at best. As previously pointed out, the public 
checking key for the digital signature of the billing agen- 
cy 13 (i.e., the supplier's digital signature) is easily em- 
bedded in all unaltered copies of the protected program 
1 1 . In this embodiment, however, the protected program 
1 1 indirectly communicates with the central billing agen- 
cy 13 via the billing computer 15. Therefore, to enable 



the protected program 1 1 to use the billing agency's pub- 
lic checking key for validating authorization messages 
which appear to the host computer 12 to be from the 
billing computer 15, one or more of the messages that 

s the billing computer 1 5 communicates to the host com- 
puter 1 2 includes a certificate or the like which is digitally 
signed by the billing agency 1 3. For example, as shown, 
this certificate passes the public checking key for the 
billing computer's secret signing key to the protected 

10 program 11 while certifying the validity of the public 
checking key for a limited time. Thus, the program 11 
can use this public checking key to authenticate the dig- 
itally signed messages that it receives from the billing 
computer 15, unless and until the billing agency's certi- 

is fication of the billing computer 15 expires. 

[0023] As a general rule, it is needlessly inefficient for 
the billing agency 13 to actively participate in preparing 
each and every authorization message that is transmit- 
ted to the host computer 12 by the billing computer 15. 

20 For this reason, the billing agency 1 3 may serially issue 
term limited authenticating certificates to the billing com- 
puter 15 in accordance with a predetermined schedule 
that is selected to ensure that an unexpired certificate 
is always in force, unless the billing agency 13 or the 

25 program supplier has decided toterminate the user's au- 
thorization to use the protected features of the program 
11 , such as for non-payment of the usage fees. To ac- 
commodate this methodology, the billing agency 15 
stores the most recently received authenticating certifi- 

30 cate for use as needed. Then, when an authorization 
message is received by the host computer 12, the pro- 
tected program 11 first checks the expiration date of the 
authenticating certificate for received message against 
the current date according to the clock 1 6 to confirm that 

35 the certificate is unexpired prior to taking any further ac- 
tion in reliance upon the apparent authorization mes- 
sage. Advantageously, the protected program 11 in- 
cludes code for causing the host computer 1 2 to contact 
the billing computer 1 5 for an authorization message 

40 each time the program 1 1 is initialized and/or periodical- 
ly while the program 11 is running, thereby ensuring a 
more or less timely reassertion of the protection for the 
program 11 if the user's usage rights are revoked or ex- 
pire. 

45 [0024] Communications from the protected program 
11 to the billing computer 15 generally are unsecure. For 
this reason, the billing computer 15 advantageously 
echoes and digitally signs all messages that it receives 
from the host computer 12 for the program 11. This en- 

50 ables the program 11 and the computer 12 to self-au- 
thenticate messages the billing computer 15 believes 
were received from them because the echoed messag- 
es are returned to the host 1 2 via an authenticated chan- 
nel (i.e., in messages that are digitally signed by the bill- 

55 jng computer 15). 

[0025] For thwarting "replay" attacks against the pro- 
tection for the software 11 , random information, such as 
a so-called "nonce", is beneficially included in each 
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message that is sent to the billing computer 15 under 
the control of the protected software 1 1 . This nonce suit- 
ably is supplied by the software 11 through the use of a 
random number generating routine. The billing compu- 
ter 15, in turn, echos this random information for return 
to the program 11 as described above. 
[0026] In the illustrated embodiment, credit is extend- 
ed to the user because the usage fees are computed by 
the billing agency 1 3 on the basis of the usage data that 
is accumulated by the billing computer 1 5. Thus, an un- 
scrupulous user could avoid paying usage fees by de- 
stroying the billing computer 15 before the usage data 
is communicated to the billing agency 13. For this rea- 
son, the billing computer 15 might be programmed to 
enforce a credit limit on the user. 
[0027] In operation, the billing agency 13 notifies the 
billing computer 15 in a digitally signed message when 
payments on the user's account are received. This en- 
ables the billing computer 1 5 to maintain a running credit 
balance on the user's account. Consequently, any bal- 
ance due on the user's account can be aged by the bill- 
ing computer 1 5 through the use of the clock 1 6. Thus, 
delinquency rules may be programmed into the billing 
computer 1 5 for determining whether future requests for 
authorization to use the protected program 11 on the 
host computer 12 should be honored or denied. As will 
be recalled, denying a re-authorization request effec- 
tively terminates the host computer's ability to execute 
the protected features of program 11 and, therefore, is 
a useful mechanism for enforcing the program supplier's 
rights. 

[0028] If desired, the protected program 11 can in- 
clude code for negotiating the terms and conditions for 
use of the protected features of the program 1 1 with pro- 
spective users. For example, the protected program 11 
might include code for presenting a prospective user 
with one after another of a plurality of feature and price 
differentiated sets of terms and conditions for usage of 
the program 1 1 , thereby giving the prospective user the 
freedom to "accept" any one or none of these "offers". 
Or, the code for these preliminary interactions with pro- 
spective users might provide a menu of individually 
priced, user selectable features of the program 11 . The 
accounting routines and the authorization protocols that 
are used by the billing computer 15 to manage these 
negotiated transactions would be designed to provide 
the differentiation that is necessary to discriminate be- 
tween the different options the users may select, but oth- 
erwise these negotiated transactions are governed by 
the same general principles as the simple commercial 
applications that are described above. 
[0029] An embodiment of the invention is illustrated 
by the simplified logical flow diagrams that are depicted 
by Figures 3 to 5 (the messages that are exchanged by 
these processes are depicted in dashed lines). As will 
be appreciated, the billing agency 1 3 is a trusted surro- 
gate for the shareware supplier and, therefore, can be 
viewed as being one in the same with shareware sup- 



plier, unless the billing agency 1 3 is servicing more than 
one shareware supplier. The billing computer 15, on the 
other hand, is a tamper resistant agent of the shareware 
supplier, so it is subservient to the billing agency 13 (i. 
s e., the billing agency is the superior authority). Alterna- 
tive embodiments that are consistent with this general 
framework will readily suggest themselves. For exam- 
ple, significantly more authority for managing the reac- 
tion of the protected shareware 11 to the behavior of the 
user is delegated to the billing computer 15 in the em- 
bodiment shown in Figures 1 and 2 than in the embod- 
iment shown in Figure 3. Different designers may have 
differing views on the desirability of centralizing or del- 
egating various aspects of this management control. If 
there is a generally agreed upon division of responsibil- 
ities between the billing agency 13 and the billing com- 
puter 15, then the same billing computer 15 and the 
same billing agency 1 5 can be employed to service mul- 
tiple shareware offerings of the same or different sup- 
pliers by simply extending the same general support 
framework to each of those offerings. 
[0030] In view of the foregoing, it will be understood 
that this invention effectively provides a low cost soft- 
ware distribution technique which has many of the most 
desirable characteristics of the existing shareware dis- 
tribution model, but which has the advantage of more 
strongly enforcing the program supplier's rights, such as 
the right to be paid usage fees in commercial applica- 
tions. 



30 

Claims 

1. A method for protecting an executable computer 
35 program from unauthorized use independently of 
any methodology for distributing said program to 
prospective users; said method comprising the 
steps of: 

40 inhibiting at least some functional feature of 

said program from running on a compatible 
stored program computer until said computer 
receives a message that is digitally signed by 
an authorized party using a secret signing key; 

45 providing said program access to a public 

checking key for said secret signing key in said 
program; 

running an integrity self-check over said pro- 
gram to confirm that said program is in an an- 

so ticipated state; 

communicating a message that is digitally 
signed with said secret signing key to said com- 
puter for tentatively approving the running of 
said functional feature of said program on said 

55 computer; 

applying said public checking key to said digit- 
ally signed message for authenticating it; and 
enabling said functional feature to run on said 



15 



20 



6 



11 EP 0 913 757 A2 12 

selected computer in response to the authenti- 
cation of said message, provided that it has 
been confirmed that said program is in said an- 
ticipated state. 

2. The method of claim 1 , wherein: 

said message is supplied by an agent and is 
digitally signed by said agent using a first secret 
signing key; 

said agent's authority to issue said message is 
certified by a superior authority for by a certifi- 
cation that is signed with a second secret sign- 
ing key and which authenticates a public check- 
ing key for said first signing key; 
said certification is communicated to said pro- 
gram; 

said program has access to and is able to au- 
thenticate a public checking key for said second 
secret signing key, thereby enabling said pro- 
gram to authenticate said certification. 

3. The method of claim 2, wherein: 

sard public checking key for said second se- 
cret signing key is embedded in said program, 25 
whereby said integrity self-check authenticates said 
public checking key for said second secret signing 
key. 

4. The method of claim 2 or claim 3, wherein: 30 

said agent participates in a commercial trans- 
action with each user to offer the user an opportu- 
nity to run said functional feature of said program in 
return for certain consideration and to monitor the 
user's return of said consideration if said offer is ac- 35 
cepted. 

5. The method of claim 4 wherein said commercial 
transaction involves a multiple option offer which 
covers multiple functional features of said program 40 
and multiple pricing plans. 
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f The billing agency 



"User A paid his 50 cent 
bill this month, 5/98. Billing 
computer 8347234234 can 
keep running his software." 
Signed: The billing agency. 



"User A's total software usage 
this month, 5/98. 50 cents for 
use of Fred's Fine Software" 
Signed: the billing computer 
with public key 8347234234 




Billing info: "Pay 50 cents to Fred's Fine Softw are/' 
Nonce: 92849606983629590 




'The billing info is: pay 50 cents 
to Fred's Fine Software. 
The nonce is: 92849606983629590. 
You are authorized to execute." 
Signed: the billing computer 
with public key 8347234234 



Certificate: "Public key 8347234234 
is valid until 12/31/98." 
Signed: The billing agency. 



V USER A's COMPUTER J 



FIG. 7 
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INITIALIZE 
PROTECTED PROGRAM 



RUN INTEGRITY 
SELF-CHECK 




RUN PROGRAM WITH 
BASIC FUNCTIONALITY 



OFFER EXTENDED 
FUNCTIONALITY 



TRIGGER 
COUNTERMEASURES 




C EXIT > 
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REQUEST USAGE 
AUTHORIZATION 



MSG 



Y *A 

(TO FIG. 4) 




RUN INTEGRITY 
SELF-CHECK 




TRIGGER 
COUNTERMEASURES 
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c exit : > 



RUN PROGRAM 
WITH EXTENDED 
FUNCTIONALITY 



REPORT USAGE 




MSGS ^ 
>C 

(TO FIG. 4) 



FIG. 3 
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INITIALIZE 
PROCESS 
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(FROM FIG.3) 
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ACCOUNT STATUS 
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(TO/FROM FIG. 5) 
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